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Generic Routing Encapsulation (GRE) Key Extension for Mobile IPv4 
Abstract 


The Generic Routing Encapsulation (GRE) specification contains a Key 
field, which MAY contain a value that is used to identify a 
particular GRE data stream. This specification defines a new Mobile 
IP extension that is used to exchange the value to be used in the GRE 
Key field. This extension further allows the Mobility Agents to set 
up the necessary protocol interfaces prior to receiving the mobile 
node traffic. The new extension allows a Foreign Agent to request 
GRE tunneling without disturbing the Home Agent behavior specified 
for Mobile IPv4. GRE tunneling with the Key field allows the 
operators to have home networks that consist of multiple Virtual 
Private Networks (VPNs), which may have overlapping home addresses. 
When the tuple «Care of Address, Home Address, and Home Agent 
Address» is the same across multiple subscriber sessions, GRE 
tunneling will provide a means for the Foreign Agent and Home Agent 
to identify data streams for the individual sessions based on the GRE 
key. In the absence of this key identifier, the data streams cannot 
be distinguished from each other -- a significant drawback when using 
IP-in-IP tunneling. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6245. 
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Copyright Notice 


Copyright (c) 2011 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 


This document specifies a new extension for use by a Foreign Agent 
(FA) operating Mobile IP for IPv4. The new extension allows a 
Foreign Agent to request Generic Routing Encapsulation (GRE) 

[RFC2784] tunneling without disturbing the Home Agent (HA) behavior 
Specified for Mobile IPv4 [RFC5944]. This extension contains the GRE 
key [RFC2890] required for establishing a GRE tunnel between the FA 
and the HA. 


GRE tunneling with the Key field allows the operators to have home 
networks that consist of multiple Virtual Private Networks (VPNs), 
which may have overlapping home addresses. When the tuple «Care of 
Address, Home Address, and Home Agent Address» is the same across 


Yegani, et al. Standards Track [Page 2] 


RFC 6245 GRE Key Ext. for MIP4 May 2011 


4. 


multiple subscriber sessions, GRE tunneling will provide a means for 
the FA and the HA to identify data streams for the individual 
sessions based on the GRE key. In the absence of this key 
identifier, the data streams cannot be distinguished from each other 
-- a significant drawback when using IP-in-IP tunneling. 


Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. Other 
terminology is used as already defined in [RFC5944]. 


GRE Key Extension 

The format of the GRE Key Extension conforms to the extension format 
Specified for Mobile IPv4 [RFC5944]. This extension option is used 
by the Foreign Agent to supply GRE key and other necessary 
information to the Home Agent to establish a GRE tunnel between the 
FA and the HA. 

Operation and Use of the GRE Key Extension 
1. Foreign Agent Requirements for GRE Tunneling Support 


The FA MUST support IP-in-IP tunneling of datagrams for Mobile IPv4 


[RFC5944]. The FA may support GRE tunneling that can be used, for 
example, to allow for overlapping private home IP addresses 
(Section 4.2.2.5 of [X.S0011-E]). If the FA is capable of supporting 


GRE encapsulation, it should set the 'G' (GRE encapsulation) bit in 
the Flags field in the Agent Advertisement message sent to the Mobile 
Node (MN) during the Mobile IP session establishment. 


If the MN does not set the 'G' bit, the FA MAY fall back to using 
IP-in-IP encapsulation for the session per [RFC5944]. 


If the MN does not set the 'G' bit and does not set the 'D' 
(Decapsulation by mobile node) bit (i.e., the mobile node does not 
request GRE tunneling and is not using a co-located care-of address), 
and the local policy allows the FA to override the 'G' bit setting 
received from the MN, the FA MUST include the GRE Key Extension as 
defined in this memo in the Registration Request (RRQ) that it 
propagates to the HA. The presence of this extension is a request 
for GRE encapsulation that takes precedence over the setting of the 
'G' bit in the Registration Request. The FA MUST NOT modify the 'G' 
bit in the Registration Request because it is protected by the 
Mobile-Home Authentication extension. 
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If the FA does not support GRE encapsulation, the FA MUST reset the 
'G' bit in the Agent Advertisement message. In this case, if the MN 
sets the 'G' bit in the Registration Request message, the FA returns 
a Registration Reply (RRP) message to the MN with code 'requested 
encapsulation unavailable' (72) per [RFC5944]. 


If the FA allows GRE encapsulation, and either the MN requested GRE 
encapsulation or local policy dictates using GRE encapsulation for 
the session, and the 'D' bit is not set (i.e., the mobile node is not 
using a co-located care-of address), the FA MUST include the GRE Key 
in the GRE Key Extension in all Mobile IP Registration Requests 
(including initial, renewal, and de-registration requests) before 
forwarding the request to the HA. The FA may include a GRE key of 
value zero in the GRE Key Extension to signal that the HA assigns GRE 
keys in both directions. The GRE key assignment in the FA and the HA 
is outside the scope of this memo. 


The GRE Key Extension SHALL follow the format defined in [RFC5944]. 
This extension SHALL be added after the MN-HA and MN-FA Challenge and 
MN-AAA (Mobile Node - Authentication, Authorization, and Accounting) 
extensions (if any) and before the FA-HA Auth extension (if any). 


4.2. Home Agent Requirements for GRE Tunneling Support 


The HA MUST follow the procedures specified in [RFC5944] in 
processing this extension in Registration Request messages. 


If the HA receives the GRE Key Extension in a Registration Request 
and does not recognize this non-skippable extension, it MUST silently 
discard the message. The HA MUST use other alternative forms of 
encapsulation (e.g., IP-in-IP tunneling), when requested by the 
mobile node per [RFC5944]. 


If the HA receives the GRE Key Extension in a Registration Request 
and recognizes the GRE Key Extension but is not configured to support 
GRE encapsulation, it MUST send an RRP with code 'requested 
encapsulation unavailable (139)' [RFC3024]. 


If the HA receives a Registration Request with a GRE Key Extension 
but without the 'G' bit set, the HA SHOULD treat this as if the 'G' 
bit is set in the Registration Request; i.e., the presence of a GRE 
Key Extension indicates a request for GRE encapsulation. 


If the HA receives the GRE Key Extension in a Registration Request, 


and it recognizes the GRE Key Extension as well as supports GRE 
encapsulation, the following procedures should apply: 


Yegani, et al. Standards Track [Page 4] 


RFC 6245 GRE Key Ext. for MIP4 May 2011 


o The HA SHOULD accept the RRQ and send an RRP with code 
'registration accepted (0)'. 


o The HA MUST assign a GRE key and include the GRE Key Extension in 
the RRP before sending it to the FA. 


o The HA MUST include the GRE Key Extension in all RRPs in response 
to any RRQ that included the GRE Key Extension, when a GRE key is 
available for the registration. 


If the HA receives the GRE Key Extension in the initial Registration 
Request and recognizes the GRE Key Extension carrying a GRE key value 
of zero, it SHOULD accept the RRQ and send an RRP with code 
'registration accepted (0)', and the following procedures apply: 


o The HA MUST assign GRE keys for both directions and include these 
keys in the GRE Key Extension in the RRP before sending it to 
the FA. 


o The HA MUST include the GRE Key Extension in the RRP in response 
to the initial RRQ that included the GRE Key Extension, when a GRE 
key is available for the registration. 


4.3. Mobile Node Requirements for GRE Tunneling Support 


If the MN is capable of supporting GRE encapsulation, it SHOULD set 
the 'G' bit in the Flags field in the Registration Request per 
[RFC5944]. 


5. GRE Key Extension and Tunneling Procedures 


GRE tunneling support for Mobile IP will permit asymmetric GRE 
keying; i.e., the FA assigns a GRE key for use in encapsulated 
traffic, and the HA can assign its own GRE key. Once the GRE keys 
have been exchanged, the FA uses the HA-assigned key in the 
encapsulating GRE header for reverse tunneling, and the HA uses the 


= 


FA-assigned key in the encapsulating GRE header. 


The format of the GRE Key Extension is as shown below. 


The GRE Key Extension MAY be included in Registration Requests or 
Registration Replies [RFC5944]. The GRE Key Extension is used to 
inform the recipient of the Mobile IP request of the value to be used 
in the GRE Key field. 
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0 1 2 3 
0123456789 0123456789012345678901 
(——————R—————————————————AR2——————————— —— tit 

| Type | Sub-Type | Length 

———RBAAR——————^———————X—A^»—————— M —Ó 
| Key Identifier | 
€————R——————————————A—A^A—A^A—————————————— S 


Figure 1: GRE Key Extension 
Type 


48 - An 8-bit identifier of the GRE Key Extension type 
(non-skippable) 


Sub-Type 


Length 


Key Identifier 


This is a four-octet value assigned during registration and 
inserted in every GRE packet of the user traffic. 


6. IANA Considerations 
The GRE Key Extension defined in this memo is a Mobile IP extension 
as defined in [RFC5944]. IANA has assigned a Type value (48) for 
this extension from the non-skippable range (0-127). 
The GRE Key Extension introduces a new sub-type numbering space, 
where the value 0 has been assigned from the range 0 to 255. 
Approval of new GRE Key Extension sub-type values is to be made 
through Expert Review with Specification Required. 


7. Security Considerations 


This specification does not introduce any new security 
considerations, beyond those described in [RFC5944]. 
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Despite its name, the GRE Key Extension has little to do with 
security. The word "Key" here is not used in the cryptographic sense 
of a shared secret that must be protected but rather in the sense of 
an "index" or demultiplexing value that can be used to distinguish 
packets belonging to a given flow within a GRE tunnel. 
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